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PREFACE 


This  report  presents  a  conceptual  design  for  a  computer  graphics 
program  capable  of  displaying  arbitrary  data  bases.  The  program  was 
motivated  by  a  need  to  provide  new  dimensions  in  information  presenta¬ 
tion  to  researchers  studying  the  dynamics  of  climate.  Sponsored  by 
the  Defense  Advanced  Research  Projects  Agency,  Office  of  Information 
Processing  Techniques,  the  new  program  is  an  integral  part  of  an  over¬ 
all  effort  by  DARPA  and  Rand  to  expand  the  use  of  computer  resources 
in  military  environments. 

There  is  a  specific  need  for  the  application  of  advanced  graphical 
display  techniques  to  climatological  studies.  The  main  purpose  of  the 
report,  however,  is  to  serve  at  a  guideline  in  implementing  the  program 
on  a  PDP-10  computer.  Thus  the  report  is  primarily  directed  to  the 
implementer,  who  is  assumed  to  be  familiar  with  the  PDP-10  TENEX  oper¬ 
ating  system  and  with  the  BLISS  language. 


!W<<Kr.»*«wxsrKV*Lv<»*w-,s 


-v- 


SUMMARY 


This  is  a  report  of  progress  in  an  ongoing  ARPA-sponsored  project 
to  support  research  into  the  dynamics  of  climate.  It  describes  the 
planned  interactive  graphic  computer  program,  VIEW  (Video  Information 
Exchange  Window) ,  which  is  intended  to  interface  between  a  graphics 
terminal  user  and  his  specific  application  program  to  display  and  manip¬ 
ulate  whatever  local  or  remote  data  base  he  chooses  to  access.  VIEW 
assists  in  a  wide  variety  of  actions,  from  laying  out  a  logic  display 
to  plotting  contour  maps  and  constructing  original  graphics. 

There  are  no  restrictions  on  the  nature  and  purpose  of  the  appli¬ 
cation  programs  that  VIEW  serves,  nor  on  the  syntax  the  user  employs  to 
communicate  with  the  programs  through  VIEW.  VIEW  converses  with  the 
application  program  only  through  a  simply  structured  data  file;  the  pro¬ 
gram  and  VIEW  operate  in  parallel.  VIEW  ordinarily  understands  the 
syntax  of  a  user's  request  but  does  not  interpret  the  semantics,  except 
for  a  few  direct  requests.  VIEW's  syntax  checking  can  also  be  bypassed 
when  the  user  wishes  only  to  use  VIEW  to  pass  information  to  the  appli¬ 
cation  program. 

To  illustrate  the  way  a  user  interacts  with  VIEW,  several  examples 
are  given  of  using  VIEW  to  create  graphs,  diagrams,  and  contour  maps 
and  to  tabulate  numeric  data.  Following  this  introduction  to  the  lan¬ 
guage  by  scenario,  the  syntax  and  semantics  of  the  VIEW  "picture  language" 
are  explained.  The  picture  language  operates  on  a  VIEW-created  inter¬ 
mediate  data  base,  called  a  piotuvsfile ,  not  directly  on  the  user's  data 
base.  A  picturefile  contains  the  data  and  display  codes  necessary  for 
one  particular  picture  or  other  screen  display.  Pictureflles  can  be 
superimposed  for  display  purposes . 

To  simplify  the  user  s  task,  a  collection  of  sample  system  picture- 
files  is  available,  with  generally  acceptable  values  for  graphs,  con¬ 
tours,  and  other  displays.  A  user  may  retrieve  a  copy  of  any  desired 
sample,  modify  it  as  desired,  and  store  the  result  under  a  new  name.  In 
all  cases,  VIEW  provides  default  values  for  all  display  options.  Hard¬ 
copy  of  any  display  can  be  obtained,  as  can  a  listing  of  the  variables. 

Preceding  page  blank 
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From  the  terminal,  the  user  may  annotate  any  display,  via  the  key¬ 
board,  light  pen,  or  Rand  Tablet  stylus.  He  may  also  create  his  own 
displays  by  choosing  from  a  menu  of  displayed  options  (e.g.,  line  seg¬ 
ments,  arcs,  strings)  and  touching  the  points  at  which  each  is  to  appear 
on  the  screen,  such  as  the  end  points  of  a  line.  Three  levels  of  in- 
temity  are  available  for  any  element — dim,  normal,  or  bright.  Lines 
may  be  solid,  dashed,  composed  of  symbols,  etc.  The  user  can  duplicate, 
delete,  modify,  or  move  any  element  in  a  display.  A  user-defined  proto¬ 
type  can  be  filed  and  recalled  as  desired. 

To  serve  as  a  guideline  for  the  implementer,  the  program  organiza¬ 
tion  and  data  structure  (the  picturefile  format)  are  spelled  out  in 
some  detail.  The  program  is  partitioned  into  functional  subroutines 
1:0  permit  piecewise  implementation,  with  later  additions  in  response  to 
user  feedback.  The  special  support  software  for  the  specific  classes 
of  displays  is  modular  and  insulated  from  the  main  body  of  VIEW,  to  allow 
new  modules  to  be  added  conveniently.  The  device-dependent  portion  of 
the  software  package  is  insulated  from  the  remainder  of  the  program,  to 
make  it  readily  adaptable  to  different  graphic  hardware. 

The  implementation  plan  for  VIEW  specifies  a  PDP-10  computer,  using 
its  TENEX  operating  system  and  the  BLISS  language,  with  Rand  Video 
Graphics  terminals.  Familiarity  with  TENEX  and  BLISS  is  necessary  for 
complete  understanding  of  the  details. 

The  graph  and  contour  plotting  portions,  with  appropriate  network 
access  by  external  processes,  are  expected  to  be  complete  within  6  months. 
VIEW  is  expected  to  evolve  over  some  time,  in  response  to  user  needs  and 
reactions . 
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I .  INTRODUCT ION 


SCOPE  OF  THE  GRAPHICS  PROGRAM 

The  VIEW  program  (Video  Information  Exchange  Window)  is  intended 
to  assist  graphics  terminal  users  in  a  variety  of  actions,  from  laying 
out  logic  displays  to  plotting  contour  maps.  Basically,  VIEW  inter¬ 
faces  between  the  user  and  his  specific  application  program  to  display 
whatever  local  or  remote  data  base  he  chooses  to  access.  Remotely 

located  data  bases  will  be  accessed  via  the  ARPANET  (ARPA  Experimental 
Computing  Network) . ^ 

The  design  of  VIEW  was  shaped  by  the  criteria  of  a  general-purpose 
program.  As  a  result: 

•  There  are  no  restrictions  on  the  nature  and  purpose  of 
the  application  processes  that  VIEW  serves,  nor  on  the 
syntax  the  user  employs  to  communicate  with  these  pro¬ 
cesses  through  VIEW. 

•  VIEW  converses  with  an  application  program  only  through 
a  simply  structured  data  file.  VIEW  and  the  application 
program  execute  in  parallel  and  communicate  only  through 
the  data  base. 

•  VIEW  ordinarily  understands  the  syntax  of  a  user's  re¬ 
quests  but,  except  for  a  few  direct  requests,  does  not 
interpret  the  semantics.  The  meaning  of  his  actions 

is  understood  and  acted  upon  by  his  application  program. 

•  An  escape  request  and  a  return  request  enable  VIEW's 
syntax  checking  to  be  bypassed  if  the  user  wishes  to 
pass  information  transparently  to  the  application  pro¬ 
gram  through  VIEW. 

•  The  special  support  software  for  creating  specific  classes 
of  displays,  such  as  x-y  plots,  is  modular  and  insulated 
from  the  main  body  of  VIEW.  The  resulting  program 
organization  allows  new  modules  to  be  added  conveniently. 
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The  device-dependent  portion  of  the  graphics  support 
package  is  insulated  from  the  remainder  of  the  program, 
to  make  it  readily  adaptable  to  different  graphic 
hardware . 


The  implementation  plan  for  VIEW  specifies  a  PDP-10  computer, (2) 
its  TENEX  operating  system, and  the  BLISS  language. Familiarity 
with  these  is  necessary  for  complete  understanding  of  this  report. 


A  CLIMATE  DYNAMICS  APPLICAT ION 


Although  the  purpose  and  scope  of  VIEW  are  general,  the  concept 
arose  from  the  particular  needs  of  a  Rand  project  that  studies  the 
dynamics  of  climate.  This  project  is  heavily  dependent  upon  large 
simulation  and  analysis  programs.  Characteristic  of  these  simulation 
programs  is  the  production  of  large  volumes  of  data.  One  60-day  simu¬ 
lation  now  produces  roughly  8  million  numbers .  Special  analysis  pro¬ 
grams  reduce  and  manipulate  the  output  of  the  simulations.  The  sheer 


difficulty  of  handling  so  much  data  and  the  lack  of  a  convenient  mech¬ 
anism  to  get  the  data  into  a  form  germane  to  the  researcher  have  hampered 
progress  in  this  important  field  of  study. 

A  cursory  look  at  the  amount  of  data  associated  with  just  one  such 
simulation  program,  the  Mintz-Arakawa  Two-Level  Atmospheric  General 
Circulation  Model,  ^  will  illuminate  the  problem.  Data  from  the  simu¬ 
lation  runs  are  maintained  on  disk  packs  housing  approximately  30  million 
8-fcit  bytes.  At  present,  two  packs  are  required  to  hold  the  results  of 
a  simulated  60-day  experiment.  In  the  near  future,  the  simulated  time 
will  increase  and,  on  the  average,  three  disk  packs  will  be  needed  for 


each  simulation.  The  number  of  experiments  now  stands  at  six,  with 
eight  more  likely  before  the  end  of  1973.  The  total  number  of  disk 
packs  for  60- ,  90- ,  and  120-day  simulations  will  be  around  50  by  that 
time.  This  figure  could  easily  go  as  high  as  100  pack-equivalents  when 
the  ILLIAC  IV^6,7)  and  the  Datacomputer  (laser  store) ^8*9^  become  avail¬ 
able  on  the  ARPANET,  making  year-long  simulations  possible. 


The  climate  data  base  is  primarily  located  at  UCLA,  with  some  back¬ 
up  provided  by  the  University  of  California,  Santa  Barbara.  In  the 


future,  the  bulk  of  the  data  will  be  kept  on  the  Datacomputer  at  NASA 
Ames  Research  Center. 

There  are  now  three  methods  of  using  the  output  of  the  M/A  model. 

(1)  A  Rand  data  analysis  and  reduction  program,  called  MADAT  (Mintz- 
Arakawa  Data  Package)  retrieves  arrays  of  numbers  and  prints  them  out. 
Working  with  data  in  this  form  is  perhaps  analogous  to  a  programmer 
perusing  a  core  dump.  (2)  The  results  of  the  MADAT  printer  listing  are 
hand-plotted  as  various  kinds  of  graphs.  (3)  Alternatively,  a  set  of 
three  other  Rand  programs  called  MAPGEN ,  Map  Display,  and  Zonal  Profiles 
generates  an  intermediate  plotting  language  that  can  ultimately  be  used 
by  an  FR-80  or  other  plotter  to  produce  climate  maps.(10)  About  1400 
maps  are  produced  in  this  way  each  month.  However,  MAPGEN  is  very  large, 

slow,  and  inconvenient  to  run,  requiring  essentially  all  the  capacity  of 
UCLA's  IBM  360/91. 


VIEW  GUIDELINES 

J.t  appears  that  the  only  long-range  solution  to  this  congestion  of 
output  is  to  access  the  data  selectively  and  configure  it  dynamically, 
using  an  on-line  graphics  terminal.  With  this  goal  in  mind,  the  re¬ 
searchers  in  the  climate  dynamics  project  proffered  the  following  guide¬ 
lines  for  the  needed  graphic  support. 

The  user  should  be  able  to: 

•  Create  graphs,  contours,  bar  charts,  lists,  and  vector 
plots  that  are  user-oriented.* 

•  Look  at  a  picture  and  then  request  hardcopy. 

•  Easily  and  automatically  generate  a  standard  set  of 
graphs  from  each  simulation's  data. 

•  Request  special  graphs  and  plots  from  the  raw  data 
output  by  the  simulations  and  also  from  the  output  of 
reduction  and  analysis  programs . 

•  Graph  in  Cartesian  coordinates  with  both  linear  and 
logarithmic  scales. 


and  describes  the  graphics  support  for  graphs,  contours, 

and  lists.  Subsequent  reports  will  discuss  charts  and  vector  plots. 
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s  Scale  graphs. 

•  Produce  contour  plots  with  automatic  millibar  selections. 

•  See  a  list  of  essential  parameters,  and  enter  parameters 
directly  by  name  and  value  rather  than  by  selection  from 
a  large,  predetermined  menu. 

COMPUTER  AND  DISPLAY  EQUIPMENT 

Because  of  the  wide  variation  in  the  size  of  programs  and  the 
different  response-time  requirements,  the  data  processing  needs  of 
the  climate  workers  are  not  met  by  a  single  computer  installation. 

They  now  use  the  IBM  360/91  at  UCLA  and  the  IBM  360/75  at  UCSB  via 
the  ARPANET,  along  with  Rand's  IBM  360/65  and  PDP-10.  They  also  plan 
to  use  the  ILLIAC  IV.  These  circumstances  meld  with  the  objective 
of  making  the  graphics  program  general-purpose  to  serve  other  ARPA- 
sponsored  projects  at  Rand,  and  perhaps  the  network  community.  The 
equipment  around  which  the  VIEW  program  was  planned  consists  of  the 
Rand  PDP-10  TENEX  system' and  the  Rand  Video  Graphics  System. (11) 
However,  VIEW  may  be  implemented  on  different  graphic  consoles. 

PROGRAM  GOALS  AND  IMPLEMENTATION  STRATEGY 

The  overall  goals  of  the  graphic  support  program  are: 

»  Primarily,  to  provide  a  graphic  facility  for  researchers 
and  programmers  to  examine  climatological  data  bases. 

•  Secondarily,  to  provide  a  graphic  facility  for  any  ARPA- 
sponsored  projects,  at  Rand  and  elsewhere. 

The  implementation  strategy  is  to  offer  parts  of  the  program  as 
soon  as  possible,  reflect  on  their  use,  and  then  decide  which  parts  to 
complete  next.  The  first  milestone  includes  the  subset  of  VIEW  (along 
with  retrieval  and  display  processes)  needed  to  support  graphs. 
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II.  APPEARANCE  TO  THE  USER 


SCENARIOS 

It  is  instructive  to  examine  the  user's  view  of  the  system  from 
two  different  directions.  First,  we  provide  several  scenarios  showing 
the  use  of  the  system,  without  a  formal  description  of  the  syntax  and 
semantics  of  the  commands  and  operations  being  performed.  The  scenarios 
give  some  feeling  for  the  nature  of  the  graphics  program.  Once  this 
feeling  is  conveyed,  further  details  of  the  language  for  the  user  of 
the  system  are  explained,  with  appropriate  mention  of  options  and 
defaults . 

Selecting  Data  for  Analysis 

To  obtain  graphic  output  of  data,  a  system  user  must  go  through 
two  distinct  processes:  (1)  he  must  retrieve  the  data  to  be  displayed, 
and  (2)  he  must  specify  the  parameters  required  to  create  the  display 
in  the  desired  format . 

Since  the  graphics  program  is  application-independent,  the  program 
retrieving  the  data  is  regarded  by  VIEW  as  a  separate  entity.  Thus, 
the  graphics  program  does  not  examine  the  inputs  to  that  program.  To 
enter  these  inputs,  the  user  presses  an  escape  key  (($))  on  the  keyboard, 
enters  the  retrieval  parameters,  and  returns  to  the  normal  input  mode 
with  another  escape  key,  as  shown  below. 


© 

I  free-form  retrieval  requests 

© 


If  the  user  then  types  RETRIEVE,  the  application-specific  retrieval 
process  is  initiated  as  a  parallel  task.  The  retrieval  process  may  be 
in  the  same  system  or  it  may  be  remotely  accessed  over  the  ARPANET. 

When  completed,  the  process  returns  the  selected  data  to  the  VIEW  graph¬ 
ics  program  as  a  data  file. 
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Generating  an  X-Y  Graph 

After  the  desired  data  have  been  retrieved,  the  user  may  request 
a  graph.  If,  for  example,  he  enters 

X  =  ALTITUDE 
Y  =  PRESSURE 
GRAPH 

he  requests  that  the  vector  of  numbers  called  ALTITUDE  (retrieved  data) 
be  plotted  agains  the  vector  of  numbers  called  PRESSURE  (retrieved  data) , 
using  the  system  default  values  for  graphs.  On  his  display  screen  will 
appear  a  graph  such  as  the  one  shown  in  Fig.  1. 


Fig.  1  — VI EW-created  graph 

By  using  the  default  values,  the  system  has  fitted  the  graph  exactly 
to  the  data;  it  has  used  the  data  extremes  to  label  the  x  and  y  axes,  and 
the  x  and  y  variable  names  for  the  legends  on  the  x  and  y  axes. 


-7- 


If  the  user  wants  grid  lines,  with  different  limits  on  the  axes, 
he  can  enter  the  statement  shown  below: 

XSCALE  =0,  80,  10 
YSCALE  =0,  50,  5 
GRAPH 

These  requests  specify  that  he  wants  the  x  axis  to  run  from  0  to  80  with 
grid  lines  every  10  units,  and  the  y  axis  to  run  from  0  to  50  with  grid 
lines  every  5  units.  As  a  result,  he  will  see  a  display  similar  to  that 
shown  in  Fig.  2. 


Pig<  2  —  ViEW-created  graph  with  grid  lines 


Generating  a  Scatter  Diagram 

Scatter  diagrams  are  similar  to  graphs,  except  that  there  is  no 
necessary  dependency  relationship  between  the  x  and  y  variables.  For 
example,  the  user  may  make  the  following  request: 


X  =  PRESSURE,  TIME  =  400,  435,  5 
Y  =  HUMIDITY 


In  this  case,  time  is  the  independent  variable  that  is  not  being  plotted. 
Hence,  if  the  user  were  to  type  GRAPH,  the  result  would  appear  as  shown 
in  Fig.  3,  which  would  be  of  little  value  as  a  graph. 


Pressure 


Fin.  3  Result  of  plotting  independent  variables 


Since  the  user  really  wants  a  scatter  diagram,  he  will  type 


Y  TYPE  =  + 
GRAPH 


to  indicate  that  the  type  of  plot  is  the  symbol  "+"  rather  than  the 
standard  connected  line  segments.  These  commands  will  result  in  a  dis¬ 
play  similar  to  that  shown  in  Fig.  4,  which  is  the  desired  scatter 
diagram. 

Generating  a  Contour 


A  typical  way  for  the  user  to  examine  three-dimensional  information 
13  °  View  the  data  ±n  the  form  of  a  contour  plot.  If,  for  example,  his 


■  -  \’Mv*8*T»i5X*sc 


29.12 


30.07 


Pressure 

Fig,  4  Scatter  diagram  of  the  same  points  as  in  Fig .  3 

data  are  an  array  of  pressures  over  the  surface  of  the  earth,  with  lati¬ 
tude  and  longitude  the  two  Indices,  he  ,111  probably  want  to  examine 

the  data  as  a  contour  plot.  Such'  a  display  can  be  obtained  by  entering 
the  following  requests: 

X  =  LONGITUDE 

Y  =  LATITUDE 

Z  =■  PRESSURE 

INTERVAL  =  100,  300,  100 

CONTOUR 

•niase  requests  specify  that  he  wants  pressure  as  the  third  dimension 
an  that  he  wants  the  contours  to  run  from  100  to  300  at  Intervals  of 
100.  Ihe  result  will  be  the  display  shown  In  Fig.  5. 

To  make  the  display  more  Informative,  the  user  may  want  to  specify 
a  base  contour  of,  say,  100,  and  to  have  that  contour  dashed  Instead 
Of  solid.  He  can  do  this  by  requesting 


BASE  =  100 

BASE  TYPE  =  DASHED 

CONTOUR 
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11118  Wil1  yield  the  disPlay  sh°wn  in  Fig.  6,  which  identifies  the  100- 
level  contour  more  prominently. 
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Famllies  of  Curves 

It  is  often  desirable  to  compare  sets  of  data  that  have,  in  the 
case  of  x-y  graphs,  the  same  x  and  y  variables,  but  are  distinct  in  a 
third  dimension.  Such  a  display  would  appear  as  shown  in  Fig.  7. 


This  display  can  be  created  by  (1)  superimposing  picturefiles  or  (2) 
allowing  multiple  variables  specifying  the  information  to  be  plotted 
as  the  dependent  variable.  In  response  to  user  feedback  on  the  initial 
VIEW  system,  one  of  these  alternatives  will  be  implemented  in  the  second- 
generation  system. 

Generating  Lists 

Frequently,  a  user  may  want  to  have  a  scalar,  vector,  or  array 
displayed  numerically,  rather  than  in  some  graphical  format.  To  specify 
the  manner  in  which  the  data  are  displayed,  the  user  can  assign  a  format 
descriptor  as  the  value  of  a  variable,  e.g., 


variable name  =  format 
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The  syntax  of  the  format  descriptor  is  similar  to  that  used  in 
®  (12)  * 
JOSS  ,  with  some  modifications  to  satisfy  the  VIEW  requirements , 


Within  the  format  descriptor,  fields  in  which  numeric  data  will  be 
stored  are  indicated  by 


•  A  string  of  underscores  with  an  optional  decimal  point 
to  indicate  standard  decimal  notation. 

•  A  string  of  periods  to  indicate  scientific  notation. 

All  other  characters  may  be  used  to  separate  fields  and  co  indicate 
literals.  For  example,  the  statement 


F  =  INT  =  _  FP  =  SN  - 

""  J  ""  • ""  )  •  •  •  • 

makes  F  a  variable  whose  value  is  a  form  to  display  an  integer  followed 
by  a  number  with  a  decimal  fraction  followed  by  a  number  in  scientific 
notation. 

The  command  LIST  obtains  a  display  of  values  in  numeric  form.  The 
argument  of  the  LIST  command  is  one  or  more  variables .  These  may  be 
variables  with  form  descriptors  as  their  values ,  or  variables  containing 
the  data  as  specified  xn  the  form.  If  a  form  is  followed  by  a  vector 
(or  vectors)  of  length  N,  the  form  will  be  applied  to  the  vector(s) 
element  by  element.  For  example,  if  X  and  Y  are  vectors  of  length  5, 
then 


FI  ■  X  Y 


would  specify  a  heading; 


F2  = 


would  specify  a  two-column  format  for  the  numbers;  and 


The  JOSS  format  was  imitated  as  a  convenience  to  the  users,  who 
are  typically  familiar  with  JOSS. 
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LIST  FI,  F2,  X,  Y 


would  display 

X  Y 

12.4  77.2 

17.5  71.6 

19.2  84.2 

20.7  99.1 

91.4  47.6 

The  display  of  a  list  of  numbers  Is  transient;  it  is  generated 
afresh  each  time  the  user  requests  the  display.  If  a  permanent  record 
is  desired,  the  user  types  the  command 


HARDCOPY. 


LANGUAGE  SEMANTICS  AND  SYNTAX 


The  Picturefile 

To  understand  the  language  more  easily,  it  is  convenient  to  look, 
in  general  terms,  at  the  data  organization.  The  collection  of  data 
necessary  to  create  and  display  a  graph  or  other  picture  is  called  a 
picturefile .  A  picturefile  has  a  user-chosen  name  and,  as  the  word 
picturefile  conveys,  it  contains  the  display  codes  for  a  graph,  contour, 
or  other  picture.  Users -can  manipulate  picturefiles  through  the  picture- 
file  language.  A  picturefile  contains  some  or  all  of  the  following: 

•  The  user-specified  variables  to  retrieve  and  display  a 
graph  or  other  picture. 

•  The  retrieved  data. 

•  The  graphic  order  codes  constructed  from  the  above  two 
kinds  of  data. 

•  Any  direct  inputs  from  the  user  at  his  console  (called 
annotation  or  comments). 
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Picturefiles  can  be  superimposed  for  display  purposes.  They  can 
be,  hardcopied;  their  variables  can  be  listed,  etc.  Picturefiles  are 
TENEX  files;  thus,  the  system's  executive  file  commands  apply  to  them, 
as  well  as  those  commands  supported  directly  by  VIEW. 

Kinds  of  Picturefile  Variables 

A  picturefile  contains  an  arbitrary  number  of  variables .  The 
kinds  of  variables  are: 

•  Annotations  or  user  graphics  (e.g.,  joined  lines,  hori¬ 
zontal  lines,  vertical  lines,  character  strings,  arcs). 

•  Reserved  variables. 

•  Transparent  variables,  which  VIEW  passes  to  the  appli¬ 
cation  program  without  interpretation. 

Annotation  variables  are  input  directly  by  the  terminal  user ,  via 
light  pen  or  stylus,  and  are  understood  by  an  annotation  subroutine  in 
VIEW.  They  provide  a  way  for  the  user  to  freely  annotate  his  computer¬ 
generated  pictures .  They  can  also  be  used  to  construct  new  graphics , 
as  described  below,  under  "Operations  on  a  Picturefile." 

Reserved  variables ,  too,  are  understood  by  VIEW.  They  are  used 
to  associate  one  picturefile  with  another;  e.g.,  they  provide  forward 
and  backward  "links"  among  picturefiles.  They  are  also  used  to  asso¬ 
ciate  a  picturefile  with  one  or  more  arbitrary  processes  which,  in  turn, 
can  understand  the  transparent  variables» 

Transparent  variables  hold  no  meaning  for  VIEW.  They  are  acted 
upon  by  application-specific  processes ,  such  as  a  retrieval  process  for 
Mintz-Arakawa  data  or  a  display  process  for  contours.  VIEW  merely 
passes  them  on  to  the  application  program,  without  any  attempt  at  syn¬ 
tax  checking  or  interpretation. 

Attributes  of  Variables 

Each  variable  has  a  set  of  attributes  that  can  take  on  user-assigned 
values  (see  Table  1).  System  defaults  are  provided  for  each  attribute. 
Not  all  attributes  will  have  meaning  for  a  given  variable;  however,  the 
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attributes  exist  even  with  null  values.  This  organization  greatly  sim¬ 
plifies  and  generalizes  the  structural  representation  of  a  picturefile. 


Table  1 

ATTRIBUTES  OF  A  VARIABLE 


Attribute 

Description 

NAME 

a  string  specified  by  user  or  process 

SPECIFICATION 

string 

MEANING 

string 

RESULT 

bit  string 

PICTURE 

bit  string 

/  SOLID  s 

1  DASHED  / 

1  TICKS  }  for  f i8ures 

TYPE 

J  CHAR  / 

/  SMALL  )  . 

I  >  for  text 

LARGE  ) 

POSITION 

x,y  coordinates 

ORIENTATION 

-90  deg  £  integer  ^  90  deg 

(  DIM 

INTENSITY 

<  NORMAL 

(  BRIGHT 

CONTROL 

bit  string 

The  user  may  set  or  query  the  value  of  an  attribute.  Such  opera¬ 
tions  are  performed  on  the  named  variable  and  on  the  current  picturefile 
(a  picturefile  is  made  current  by  retrieving  it). 

The  NAME  attribute  is  the  name  or  label  of  a  variable. 

The  SPECIFICATION  attribute  is  a  character  string  normally  entered 
by  the  user.  It  generally  denotes  the  kind  of  data  contained  in  the  vari¬ 
able;  e.g. ,  from  the  earlier  scenarios,  where  X  ■  ALTITUDE,  the  character 
string  ALTITUDE  is  the  specification  attribute  of  the  variable  X. 
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The  MEANING  attribute  simply  defines  or  describes  the  variable  and 
is  used  for  tutorial  purposes;  e.g. ,  the  meaning  attribute  of  X  might 
be  the  character  string  "DEPENDENT  VARIABLE  AXIS." 

The  RESULT  attribute  contains  the  numeric  data  retrieved  by  an 
application-specific  process. 

The  PICTURE  attribute  contains  the  graphic  order  codes  to  produce 
a  display  of  the  numeric  data  in  an  appropriate  graphical  format. 

The  TYPE  attribute  indicates  the  line  type  or  character  size  for 
plotting  purposes. 

POSITION,  ORIENTATION,  and  INTENSITY  are  display  parameters. 

The  CONTROL  attribute  is  described  in  Sec.  Ill  of  this  report. 

System  Picturefiles 

To  simplify  the  user's  specification  task,  the  VIEW  system  includes 
a  collection  of  sample  picturefiles  with  reasonable  default  values  for 
graphs,  contours,  etc.  A  user  may  retrieve  a  copy  of  one,  modify  the 
copy,  and  store  the  result  under  a  new  name. 

Use  of  Syntactic  Forms 

The  first  syntactic  form  (variablename)  is  generally  used  to  set 
the  value  of  a  variable's  attribute.  Examples  are 

X  -  TIME,  0,  530,  1 
or 

TITLE  INTENSITY  -  NORMAL. 


The  second  syntactic  form  (request)  is  generally  used  for  file  re¬ 
quests  or  to  specify  a  continuing  mode  of  operation.  For  example: 

GET  GRAPH 
or 

DISPLAY  MENU. 

The  third  syntactic  form  (escapecharacter)  allows  the  user  to  avoid 
syntax  checking  and  to  enter  arbitrary  text  directly  into  the  picturefile. 
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The  arbitrary  text  Is  entered  as  the  value  attribute  of  a  globally  known 
variable.  The  user  then  returns  to  the  first  two  syntactic  forms  by 
entering  a  second  escape  character.  The  escape  feature  provides  two 
benefits:  The  user  can  communicate  with  an  application  process  in  what¬ 
ever  language  is  convenient  for  him,  and  can  couple  very  powerful  ex- 
trmal  processes  to  the  graphics  terminal. 

In  the  variablename  and  request  syntactic  forms,  the  attribute- 
name,  request,  and  argumentlist  may  be  abbreviated  as  the  leftmost 
character  string  that  will  identify  them  uniquely.  For  example,  the 
request  "GET"  may  be  written  as  "G"  if  there  are  no  other  requests  be¬ 
ginning  with  the  letter  G. 

Operations  on  a  Picture file 

These  operations  may  be  most  conveniently  expressed  in  tabular  form 
(see  Table  2). 

Additional  VIEW  operations  on  picturefileB  are  envisioned  to  sup¬ 
port  other  user-desired  functions — most  notably,  functions  for  super¬ 
imposing  two  or  more  picturefiles  for  comparison  of  sets  of  data. 

Operations  on  a  Variable  of  a  Plctureflle 

Each  plctureflle  consists  of  a  set  of  variables  that  define  it.  , 

Each  variable  is  in  turn  defined  by  the  values  of  its  attributes.  All 
variables  may  be  changed  through  assigning  values  to  their  attributes. 

New  variables  may  be  created  and  old  ones  purged.  All  attributes  are 
identified  by  reserved  words  in  the  VIEW  language,  and  some  attributes 
may  only  take  on  reserved  words  as  values  (see  Table  3) .  Values  of  attri¬ 
butes  initially  assume  default  values,  but  the  values  may  be  examined 
and  changed.  Some  attributes  of  some  variables  may  be  null. 

Table  3  provides  examples  of  these  operations. 

Reserved  Variables 

There  are  two  classes  of  reserved  variables— those  that  are  re¬ 
served  globally,  regardless  of  the  function  being  performed,  and  those 
that  are  reserved  in  the  context  of  the  intended  display  function  (graphs , 
contours,  etc).  There  are  four  global  variables: 
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Table  2 

OPERATIONS  ON  A  PICTUREFILE 


Operation 

Result 

GET  picturefile 

Retrieves  a  copy  of  the  picturefile,  which 
becomes  the  current  picturefile.  All  sub- 
sequent  operations  on  variables  affect 
this  image  of  the  picturefile  named 

PUT  picturefile 

Saves  current  picturefile  under  the  name 
given 

31 

Self-explanatory  operations,  initially  sup¬ 
ported  by  the  TENEX  system 

RETRIEVE 

Invokes  a  retrieval  or  computational  process 
and  points  it  at  the  current  picturefile 

GRAPH 

Invokes  a  general-purpose  graph-drawing  pro¬ 
gram  to  operate  on  the  picturefile  and 
produce  the  display  order  codes  for  a 
graph 

CONTOUR 

Invokes  a  general-purpose  contour  plotting 
routine  to  operate  on  the  current  picture- 
file  and  produce  the  display  order  codes 
for  a  contour  map 

CHART 

Invokes  a  histogram  program  to  produce  dis¬ 
play  orders  for  a  bar  chart  from  the  cur¬ 
rent  picturefile 

LIST 

Invokes  a  list  program  to  produce  display 
order  codes  for  a  tabular  listing  of  re¬ 
trieved  data  in  the  current  picturefile 

PLOT 

Invokes  a  vector  plot  program  to  produce 
display  order  codes  for  a  vector  plot 
from  the  current  picturefile  (not  illus¬ 
trated  in  this  report) 
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Table  3 

OPERATIONS  ON  ATTRIBUTES  OF  VARIABLES 


Example 

Result 

X  =  TIME 

Assigns  the  character  string  "TIME"  to 
the  specification  attribute  of  X. 

Note  that  X  =  TIME  is  equivalent  to 

X  SPECIFICATION  =  TIME;  i.e.,  if  no 
attributename  is  given,  the  specifi¬ 
cation  attribute  is  assumed.  If  X 
is  not  defined,  then  a  new  variable, 

X,  is  created. 

X  = 

Sets  the  specification  attribute  of  X 
to  null.  If  X  has  not  been  defined, 
then  a  new  variable,  X,  is  created. 

X  ? 

Displays  the  contents  of  the  specifica¬ 
tion  attribute  of  X. 

X  TYPE  ? 

Displays  the  currently  assigned  type 
attribute  of  X. 

DELETE  X 

Purges  the  variable  X  from  the  picture- 
file. 

OPTIONS  X 

Displays  the  permissible  values  of  the 
specification  attribute  of  X. 

OPTIONS  TYPE  X 

Displays  the  permissible  values  of  the 
type  attribute  of  X. 

c  NEXT  and  PREVIOUS  are  used  to  doubly  chain  picturefiles 
so  that  sets  of  displays  can  be  logically  connected. 

The  fipecification  attribute  of  these  variables  should 
name  the  appropriate  file. 

•  PROCESS  indicates  the  program  that  will  retrieve  data 
or  post-process  a  picturefile.  Its  specification 
attribute  is  the  name  of  the  program. 

•  MESSAGE  contains  in  its  specification  attribute  any 
text  that  au  external  process  wishes  to  pass  back  to 
the  user  through  VIEW  via  the  picturefile. 
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The  second  or  local  clans  of  reserved  variables  Is  much  larger. 
Those  required  for  the  display  of  x-y  graphs  have  been  specified  and 
are  explained  below: 

•  x — The  name  attribute  is  the  variable  to  be  plotted  on 
the  x-axis . 

•  y — The  name  attribute  is  the  variable  to  be  plotted  on 
the  y-axis.  The  type  attribute  of  y  specifies  whether 
the  data  points  should  be  connected  with  straight-line 
segments  or  plotted  with  a  symbol  at  each  coordinate 
pair.  The  intensity  attribute  indicates  the  intensity 
of  the  plotted  information — dim,  bright,  or  normal. 

•  XLABEL  and  YLABEL — The  specification  attribute  speci¬ 
fies  the  label  for  the  appropriate  axis.  The  inten¬ 
sity,  sire,  position,  and  orientation  attributes  have 
the  obvious  meanings. 

•  TITLE — Same  as  XLABEL,  YLABEL ,  except  that  it  repre¬ 
sents  the  title  of  the  display. 

•  XSCALE  and  YSCALE — The  specification  attributes  indi¬ 
cate  the  limits  of  the  appropriate  axis  in  the  user's 
data  space.  The  specification  attribute  may  also 
indicate  the  divisions  for  each  axis. 

•  GRID — The  type  attribute  indicates  whether  the  axis  di¬ 
visions  should  be  shown  with  tick  marks  or  grid  lines. 

The  intensity  indicates  the  intensity  of  the  entire  grid. 

•  WINDOW' — The  specification  attribute  Indicates  the  part 
of  the  screen  to  be  used  for  the  display  in  terms  of  a 
grid  of  1024  x  1024  "raster  units." 

Experience  will  probably  dictate  when  to  add  to  this  set  of  vari¬ 
ables  to  satisfy  new  requirements.  For  example,  several  curves  might 
be  required  on  a  single  grid,  in  which  case  some  method  of  "subscript¬ 
ing"  the  variables  x  and  y  would  be  appropriate. 
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Operations  on  a  Picture 

A  displayed  picture  may  be  manipulated  through  keyboard  requests 
and  through  user-entered  graphics.  The  user  can  enter  graphics  by 
selecting  from  a  displayed  list  (menu)  of  possible  options.  He  selects 
the  operation  or  graphic  element  by  pointing  at  its  name  on  the  dis¬ 
played  list  with  a  light  pen  or  tablet  stylus.  (The  program  will  in¬ 
terpret  inputs  from  both  of  these  devices.)  He  then  enters  the  other 
points  necessary  to  construct  the  graphic,  such  as  the  end  points  of 
lines . 

The  envisioned  menu  of  alternative  constructs  includes  the  follow¬ 
ing: 

•  Primitives:  strings,  "ink,"  arcs,  lines. 

•  Qualifiers:  large  characters /small  characters;  vertical/ 
horizontal/skewed  lines;  form/solid/dashed  lines;  lines 
made  up  of  symbols;  dim/normal/bright  intensity. 

•  Compounds:  graphic  structures  defined  by  the  user. 

•  Primitive  and/or  compound  operators:  duplicate;  delete; 
define;  name;  move. 

•  Global  menu  operator:  erase  screen;  scroll  compound 
list;  relocate  menu;  hardcopy. 

The  menu  is  an  implicit  part  of  each  picturefile — i.e.,  it  will  be 
added  to,  or  removed  from,  the  current  display  at  the  user's  request. 
When  the  menu  is  displayed,  the  user  can  select  functions  to  add  to  the 
current  picture,  or  can  compose  an  entire  picture  of  nothing  but  graph¬ 
ics  entered  by  him.  The  compound  function  mentioned  above  allows  the 
user  to  define  a  prototype  graphic,  save  it,  and  later  reproduce  in¬ 
stances  of  that  prototype. 
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III.  PROGRAM  ORGANIZATION  AND  DATA  STRUCTURE 

DATA  STRUCTURE  AND  PROGRAM  MAPPING 

In  this  section,  we  use  a  collection  of  diagrams  to  illustrate  the 
planned  organization  of  the  VIEW  program  and  the  associated  data  struc¬ 
tures.  VIEW  is  implemented  in  BLISS. ^ 

Figure  8  specifies  page  addresses  of  program  and  data,  and  core 
addresses  of  picturefile  components.  The  VIEW  program  and  data  proper 
precede  the  current  picturefile.  The  picturefile  is  divided  into  the 
five  segments  shown  in  Fig.  8  for  ease  of  implementation.  The  fixed 
boundary  addresses  are  quite  reasonable  in  relation  to  the  expected 
amount  of  data  comprising  any  of  the  sections.  Each  of  the  five  seg¬ 
ments  begins  with  a  two-word  segment  header  of  the  form  shown  in  Fig. 

9.  This  contains  typical  header  information:  the  location  and  the  max¬ 
imum  and  current  lengths. 

Figures  10  through  13  show  the  composition  of  a  picturefile  vari¬ 
able.  Figure  10  is  a  detailed  illustration  of  that  part  of  the  pro¬ 
gram  variable  given  in  address  epace  400000-423777  in  Fig.  8.  Figure 
11  shows  the  variable  length  specification  and  meaning  attributes,  each 
of  which  is  terminated  by  a  zero  byte.  Figure  12  shows  the  structure 
of  the  picture  attribute  of  a  variable;  intensity,  position,  and  type 
are  of  fixed  length,  and  the  CRT  order  codes  that  define  the  picture 
segment  are  of  variable  length,  a  function  of  the  picture  element 
being  described.  Figure  13  shows  the  result  attribute  of  a  retrieval 
variable. 

PROGRAM  ORGANIZATION 

VIEW  is  planned  to  be  modular  to  allow  incremental  implementation, 
as  well  as  to  facilitate  debugging  and  modification.  External  programs 
(users'  application  programs)  interface  only  through  data  in  picture- 
files  . 

The  principal  modules  of  the  program  are  shown  in  Fig.  14.  The 
pre-cormand  decoder  accepts  and  parses  the  initial  part  of  the  user's 
input  (via  light  pen,  stylus,  or  keyboard)  to  determine  the  appropriate 
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Segment  start  address 

Segment's  current  ending 
address 

Segment's  potential  maximum 
ending  address 

Segment's  maximum  permissible 
length 

Fig .  9 —  Header  of  each  picturefile  segment 


module  to  Invoke.  The  picturefile  accessor  reads  picture files  from  the 
TENEX  file  system  into  the  virtual  core  in  the  current  pictureflle  lo¬ 
cation,  and  also  writes  the  current  picturefile  into  the  TENEX  file  sys¬ 
tem.  The  picturefile  editor  is  responsible  for  editing  entries  in  the 
current  picturefile  according  f.o  the  user's  requests  entered  through  the 

keyboard.  A  typical  request  is  to  change  the  value  of  one  of  a  variable's 
attributes . 

The  annotator ,  similar  in  function  to  the  picturefile  editor,  re¬ 
sponds  to  user's  requests  containing  light  pen  data  and  possibly  text. 
Typical  requests  involve  decoding  menu  selections  and  drawing  primitive 
graphic  elements.  The  executor  acts  on  requests  for  displays  or  the 
retrieval  of  data.  It  determines  (from  the  current  picturefile  and  the 
request)  which  process  to  invoke,  and  invokes  that  process  as  a  sep¬ 
arate  fork  of  VIEW.  (A  fork  in  TENEX  is  a  parallel  process.) 

Retrieval  programs  use  the  retrieval  variables  in  the  current  pic¬ 
turefile  (or  a  named  picturefile)  to  selectively  retrieve  data  from  a 
user  s  data  base.  These  are  application-dependent  programs  provided 
by  the  u&er. 

The  display  generation  programs  (e.g. ,  graph,  contour,  etc.)  use 
the  raw  data  supplied  by  a  retrieval  program  (result  attributes  of  re¬ 
trieval  variables),  along  with  values  of  display  variables  in  the  cur¬ 
rent  picturefile,  to  create  CRT  displays.  As  currently  envisioned, 
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Fig.  12  —  Picture  attributes 


Dimension  descriptor  number  1 


Dimension  descriptor  number  k 


Dimension  width 
Dimension  name 
Lower  bound 
Increment 


Dimension  descriptor  number  n 


Variable  length  n-dimensional  binary  data 


Fig.  13  —  Result  attribute.  The  dimension  descriptor  can  be 
addressed  by  name  by  the  user  through  a  selector  function, 
which  allows  him  to  choose  either  a  row  or  a  column  vector 
from  an  array  for  graphing.  For  example,  Y  =  P  selects  a 
column  vector  P  to  graph  against  an  index  specified  by  the 
descriptor  element  that  heads  the  result  attribute  of  P. 
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each  one  of  these  programs  will  be  capable  of  generating  a  different 
class  of  displays. 

Figure  15  shows  the  interaction  of  these  programs  through  the  cur¬ 
rent  picturefile  in  simplified  form. 

INTERFACE  WITH  EXTERNAL  PROGRAMS 

The  executor  module  shown  in  Fig.  14  invokes  external  processes. 

In  the  climate  dynamics  applications,  these  processes  retrieve  raw  or 
reduced  data  for  graphing,  contouring,  etc.  In  general,  their  function 
might  well  be  to  analyze  data  entered  through  the  keyboard,  rather  than 
to  retrieve  data;  therefore,  we  shall  refer  to  external  programs  simply 
as  "processes"  rather  than  as  "retrieval  processes." 

The  (external)  process  will  be  a  started  as  a  TENEX  fork,  inferior 
to  the  VIEW  program.  The  name  of  the  TENEX  save  file  containing  the  pro¬ 
cess  must  be  the  specification  attribute  of  the  reserved  variable,  PROCESS. 

Suppose,  for  example,  the  user  is  working  with  a  copy  of  a  picture- 
file  called  GRAPH1.MINE;4  (see  Fig.  16)  and  that  he  types  RETRIEVE, 

The  executor  module  writes  the  current  picturefile  (CPF)  as  fllename.ex- 
tensionjversionnumfcer ,  using  the  next  highest  version  number — GRAPH1.MINE;5 
in  the  example.  The  executor  then  (1)  extracts  the  value  attribute  of 
the  PROCESS  variable  as  the  save-file  name  of  the  process  to  be  Initiated; 
(2)  creates  an  inferior  fork  to  the  process;  (3)  maps  the  program  into 
the  inferior  fork's  virtual  core;  (4)  loads  the  registers  with  the  pic¬ 
turefile  name  GRAPH1.MINE;5  and  then  (5)  starts  the  fork. 

The  Inferior  fork  reads  GRAPH1.MINE;5  and  performs  its  analysis  or 
retrieval;  it  then  writes  its  output  as  GRAPH l.MINE;6,  and  terminates. 
Typically,  the  contents  of  GRAPH1.MINE;6  will  be  result  attributes  and 
perhaps  the  specification  attribute  of  the  variable  MESSAGE.  The  pro¬ 
cess  can,  of  course,  write  anything  that  it  and  the  user  understand. 

The  executor  is  interrupt-initiated  upon  termination  of  the  Infe¬ 
rior  fork.  It  reads  the  value  of  each  attribute  of  each  variable  in 
GRAPH1.MINE;6  and  writes  those  values  into  the  CPF.  The  executor  re¬ 
ceives  a  success  or  failure  return  code  in  the  registers,  which  it  re¬ 
lays  to  the  user  along  with  any  message  from  the  specification  attribute 
of  the  variable  MESSAGE.  The  executor  then  deletes  GRAPH1.MINE;5  and 
GRAPH1 .MINE ; 6 . 


Jj 


Fig.  15 — Program  interface  via  current  picturefile 
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One  restriction  applies  where  the  external  process  is  working  on 
the  CPF.  Normally,  where  the  CPF  is  used,  the  user  wishes  to  start  the 
retrieval  and  analysis  while  he  sets  display  variables.  The  restriction 
is  that  he  cannot  write  (PUT)  the  CPF  until  the  inferior  fork  has  ter¬ 
minated.  This  resolves  ambiguities  such  as  the  following,  which  might 
otherwise  occur: 


GET  Q.M;1 
RETRIEVE 
PUT  R.M;1 

(inferior  fork  terminates) 

Is  Q.M; 3,  which  the  process  created,  merged  into  Q.M;1,  CPF,  or  R.M;1? 

A  SUBPROGRAM  PACKAGE  FOR  GRAPHIC  CONSTRUCTION 

VIEW  was  intended  to  run  on  the  PDP-10  with  Rand  Video  Graphics 
System  consoles,  but  may  be  implemented  on  other  graphical  consoles. 
Construction  of  graphic  order  sequences  for  displays  occurs  in  many  places 
within  VIEW  besides  the  various  display  routines  (GRAPH,  CONTOUR,  etc.). 
This  construction  is  centralized  in  a  subprogram  package  containing  the 
necessary  functions  for  the  entire  graphics  system. 

To  enable  the  user  to  request  displays  from  the  system,  create  dis¬ 
plays,  and  edit  existing  displays,  the  following  requirements  were  in¬ 
cluded  in  the  subroutine  package: 

•  The  ability  to  create  the  display  orders  for  strings 
of  text  in  both  horizontal  and  vertical  orientations. 

•  The  ability  to  create  three  classes  of  lines:  (1)  dis¬ 
crete  line  segments  specified  by  end  points;  (2)  joined 
line  segments  specified  by  end  points;  (3)  joined  line 
segments  generated  using  incremental  vectors  for  curve 
following  and  contouring. 

•  An  editing  feature  to  operate  on  existing  graphic  ele¬ 
ments.  This  includes  modifying  (1)  the  intensity  of  an 
element;  (2)  the  starting  position  of  an  element;  (3) 
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the  line  type  or  character  aize  of  an  element;  (4)  the 
contents  of  an  element  (characters  or  line  segments). 

•  A  function  to  collect  and  transmit  all  or  part  of  exist¬ 
ing  display  orders  to  the  terminal’s  graphic  display 
hardware  for  presentation  to  the  user. 

This  package  was  planned  to  be  written  in  BLISS  with  entry  points 
global  to  the  entire  graphics  system. 


i 
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IV.  DISCUSSION 


Although  the  graphics  data  presentation  system  plan  we  have  de¬ 
scribed  here  Is  an  Initial  one,  the  system  design,  in  the  main,  is  fairly 
general.  However,  some  specific  references  are  made  to  implementation 
on  a  PDP-10  TENEX  system  using  Rand  Video  Graphics  consoles.  The  selec¬ 
tion  of  different  consoles  for  the  system  does  not  greatly  alter  the 
plans  in  this  report. 

Initially  the  VIEW  system  will  be  implemented  to  use  the  MADAT  pro¬ 
gram  for  data  retrieval.  However,  the  future  availability  of  the 
Datacomputer  and  ILLIAC  IV  via  the  ARPANET  indicates  that  analysis  and 
presentation  of  remotely  located  data  will  become  more  important. 

In  general,  VIEW  is  expected  to  evolve  over  time.  The  design  of 
the  functions  for  x-y  graphs  has  been  reviewed  and  accepted  by  the  po¬ 
tential  users  and  will  be  implemented  first.  It  is  expected  that  the 
graph  and  contour  portions  of  VIEW  will  be  implemented,  with  appropri¬ 
ate  network  access  by  external  processes,  within  the  next  6  months. 

In  response  to  user  feedback,  the  plans  described  here  will  be 
modified  and  the  scope  of  the  program  expanded,  as  necessary.  We  ex¬ 
pect  eventually  to  encompass  a  large  set  of  data  representation  tech¬ 
niques  covering  several  fields  of  application. 
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